Release 10.1A: OpenEdge Development:
Messaging and ESB

Transaction and recovery procedures

A transacted session allows an application to send or receive groups of messages as one atomic operation:

A session that is transacted for sending guarantees that either all messages in a group are sent, or none is sent.
A session that is transacted for receiving guarantees that a group of received messages are acknowledged only after all messages in the group are successfully processed.

Table 4–22 lists the methods available for controlling the execution and recovery of transactions.

Table 4–22: Managing transaction attributes 

Setting	Rolling back
commitSend procedure commitReceive procedure recover procedure	rollbackSend procedure rollbackReceive procedure

The typical Java–JMS transacted application uses two sessions, one for transacted sending and one for transacted receiving. The 4GL-JMS implementation uses two JMS sessions behind the scenes, but at the 4GL API level, there is only one Session object.

The application controls whether sending, receiving, or both are transacted. It makes the session transacted by calling the setTransactedSend procedure, the setTransactedReceive procedure, or both in the Session object.

A session that is transacted for sending, receiving, or both is constantly in a transaction mode. When a transaction is committed or rolled back, a new one is automatically started.

Transacted sending

When an application calls the commitSend procedure in a Session object, all messages that have been published or sent to a queue with the current transaction are sent. When an application calls the rollbackSend procedure in a Session object, all such messages are discarded.

Transacted receiving

When an application calls the commitReceive procedure in a Session object, all messages that have been received with the current transaction are acknowledged. When an application calls the rollbackReceive procedure in a Session object, all such messages are re-received (yielding the same effect as calling the recover procedure in a nontransacted session).

Illegal calls: recover and setNoAcknowledge

Since message acknowledgement and recovery are handled automatically in a transacted session, it is an error to call the recover procedure and setNoAcknowledge procedure in a session that is transacted for receiving.

4GL transactions and JMS transacted sessions

4GL transactions and JMS transactions are not integrated. For example, a DO TRANSACTION block might be rolled back while the JMS calls inside the transaction block are committed. The 4GL application must synchronize between 4GL transactions and JMS transactions.

Note: For information about the handling of errors and error conditions, see the "Error and condition handling" section.